Repository navigation
Release: edge-apps-actions v26.10.2 (development → main) - #46
Conversation
- Removes the screen name from the app header (Screenly/edge-apps-library#56) - Regenerates screenshots to reflect the updated header
- Set STAGE_EDGE_APP_ID and PRODUCTION_EDGE_APP_ID repo variables and pass them through to the initialize/update actions as edge_app_id - Drop id from screenly.yml and delete screenly_qc.yml since a single manifest is now used regardless of environment - Pin edge-apps-actions to a commit for now, since v26.9.0 can't be tagged there until a repo ruleset is adjusted
…kflows The multi-app initialize/update-rss-reader-apps workflows target screenly_qc.yml for stage deploys independently of the standard initialize/update-edge-app actions. Deleting it broke that path.
Deploy stage on pushes to the default branch and production on vYY.M.PATCH tags, refusing tags not on the default branch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Checks, Initialize and Update now call the reusable workflows; deploys queue instead of running side by side. Dependabot checks GitHub Actions weekly and targets development, so pin bumps go through the usual flow.
Use edge-apps-actions v26.10.2 and add release badge to README
main has commits that never came back to development, so a development -> main PR conflicts. Bring them in here first. Conflict in `package.json`/`bun.lock`: took `main`'s newer dependency set. `development` only bumped `@screenly/edge-apps` to ^1.2.1, and `main` already has ^26.8.0.
There was a problem hiding this comment.
🟡 Changes recommended
Approval is blocked by a critical missing app-ID configuration that can prevent stage and production updates, plus an unenforced production tag rule; the release instructions also contain an outdated hard-coded version.
3 open issues
What changed in this PR
This pull request promotes the RSS Reader app to the edge-apps-actions v26.10.2 reusable CI/CD workflows, updates the Edge Apps dependency, and documents the CalVer release process.
Changes:
- Replaces local checks, initialization, and deployment jobs with reusable workflows.
- Updates
@screenly/edge-appsto 1.2.1 and removes the embedded app ID. - Adds development-branch checks, weekly GitHub Actions Dependabot updates, and release documentation.
- Requires changes to deployment app-ID wiring and tag validation before approval.
This pull request requires changes.
| File | Description |
|---|---|
screenly.yml |
Removes the embedded Edge App ID for variable-based deployment. |
README.md |
Adds the release badge and documents CalVer tagging and release steps. |
package.json |
Updates @screenly/edge-apps to 1.2.1. |
bun.lock |
Regenerates dependency resolutions for the Edge Apps update. |
.github/workflows/update-edge-app.yml |
Switches stage and production deployments to the v26.10.2 reusable workflow. |
.github/workflows/initialize-edge-app.yml |
Switches app initialization to the v26.10.2 reusable workflow. |
.github/workflows/checks.yml |
Runs reusable checks on supported branches and pull requests. |
.github/dependabot.yml |
Configures weekly GitHub Actions dependency updates targeting development. |
Review effort: Lite
update-rss-reader-apps.yml deployed every v* tag to production without the default-branch check update-edge-app.yml has, and also ran on tag deletion. Add the same check and skip deleted refs.
ci: only deploy feed apps to production from tags on main
Merge main into development
There was a problem hiding this comment.
🟡 Changes recommended
Two active workflow issues remain: initialization can deploy a non-main caller ref to production, and nonnumeric v* tags can still trigger production RSS deployments.
5 open issues
Restrict initialization workflow to main branch · New Enforce main-branch ancestry for all production tag deploys Pass stage and production app IDs to the reusable update job Align production tag validation with numeric CalVer pattern · New Avoid hard-coded old release version in release instructions
Review effort: Lite
There was a problem hiding this comment.
🟡 Changes recommended
Critical, moderate, and documentation issues remain unresolved, including an overly broad production deployment trigger and incorrect BBC thumbnail resizing that can cause unsafe deployments and a blurry hero image.
7 open issues
Restrict initialization workflow to main branch Enforce main-branch ancestry for all production tag deploys Pass stage and production app IDs to the reusable update job BBC image resize regex misses URLs with a two-segment path · New Align production tag validation with numeric CalVer pattern Document the new mode setting in the configuration table · New Avoid hard-coded old release version in release instructions
Review effort: Lite
There was a problem hiding this comment.
🔵 Needs a closer look
Human assessment is needed because critical hidden findings reveal inconsistent tag validation that can misclassify malformed release tags and trigger production deployments.
2 open issues
5 resolved since last review
Review effort: Lite
Replace the card grid over a photo background with a news board on the brand canvas. The lead story gets a featured image, headline and excerpt, with the remaining headlines and thumbnails listed beside it. - add mode setting: headlines (default) or a text-only list - show featured images when the feed provides them, hidden cleanly when it does not or a load fails - honour brand colours via setupTheme and isLightColor - drop bg.webp, saving about 900 KB - capture screenshots for both modes
The checks workflow only covered main, so pull requests against development ran no CI. Mirror the trigger list used by the other edge app repos.
…rss-reader # Conflicts: # bun.lock # package.json
BBC feeds only list 240px images, which blur when stretched across the lead story. Their image CDN serves the same image at other widths, so ask for one that fits the screen, rounded up to a width the CDN accepts (some, such as 1080, are a 404). If the resized image fails, fall back to the feed's own URL before hiding it. Other feeds' URLs are unchanged.
In landscape the lead story's content was taller than its column, so flex shrank the clamped headline and excerpt and cut lines through the middle. Keep them at full height, give the headline room for descenders, and limit the excerpt to two lines beside a lead image (four without one). Portrait is unchanged. Screenshots regenerated.
- Feed apps now trigger on numeric v[0-9]* tags only, like update-edge-app.yml. A single step decides production, and the tag-on-main check keys off that result, so a manual run on a tag such as vrc1 stays on stage instead of deploying all feed apps to production. - Initialize Edge App fails unless run from the default branch. The reusable workflow builds the caller's ref, so a run from a feature branch could otherwise initialize an app from unreleased code. - README release commands use a vYY.MM.N placeholder instead of the already-used v26.10.0 tag.
feat: redesign the reader as a news board
Addresses the two Copilot comments on #46. BBC image URLs come in more than one shape, and each accepts its own set of sizes. Only /ace/standard/<w>/ was resized, so video items (/images/ic/<w>x<h>/) stayed at 240x135, and /news/<w>/ URLs would have too. Each shape now has its own list of sizes, each verified against the CDN (/news/ 404s on 1280, /images/ic/ 403s on 2048x1152). The README configuration table now lists the mode setting, and rss_title's description no longer mentions the removed cards.
ci: address Copilot feedback on the release workflows
Feed apps (BBC News, Fox News, ...) all run this repo's code with their own settings and ids. They now deploy and initialize like every other Edge App, through the shared update and initialize actions, instead of custom CLI steps: - deployed-apps.yml is the only source of feed-app ids. An app without an id for the environment is skipped; before, ABC and CNN were deployed to production with an empty id on every release. - A new apply-feed-app action writes an app's deployed-apps.yml entry into screenly.yml. Everything else comes from screenly.yml, so stage no longer needs screenly_qc.yml, which is removed. - The shared actions bring a pinned CLI (v26.9.0, not @master), a token check, and, for initialize, refusal when the app already has an id or its name is taken. - Stage deploys only from the default branch, one deploy at a time per app and environment, and dispatch inputs reach scripts as environment variables. - Initialize takes an app key and reads the rest from deployed-apps.yml, so adding a feed app is: add its entry, initialize, record the id. - The unused override_app_name input is dropped. The main RSS Reader app keeps deploying through update-edge-app.yml.
fix: address Copilot feedback on the redesign
Rewriting the header comment left the old comment block behind along with a second top-level apps: key. yq and Bun take the last key, so the workflows still read the right apps, but stricter YAML parsers reject the file. Reported by Copilot on #50.
- Releasing explains that one vYY.M.PATCH tag on main releases the main app and every feed app with a production id, and uses the same version format as the other Edge App repos. - New sections cover publishing a new feed app (icon, deployed-apps.yml entry, initialize on stage then production, record the ids) and updating one (deployed-apps.yml, code or screenly.yml, one-off runs, removing an app from deploys). - DEPLOYMENT.md keeps how the feed-app workflows work and the field reference, and links to the README for the steps.
ci: deploy feed apps through the shared edge-apps-actions
docs: document releases, publishing and updating feed apps
e61a407 to
39345f2
Compare
- The cache was one shared localStorage key with no feed URL or age check. After rss_url changed and the first fetch failed, the old feed's stories showed under the new title, and during an outage cached stories stayed up indefinitely. Caches are now kept per feed URL, ignored after 24 hours, and the legacy key and other feeds' expired caches are removed on save. - An empty feed falls back to the cache like a failed fetch, instead of blanking the screen. - cache_interval is clamped to 60-86400 seconds. 0 or a tiny value refetched the feed in a tight loop, and a huge one overflowed setInterval, which then fires immediately. - README: warn that any v<digit> tag, including pre-release tags, deploys to production; say overrides need an app key; explain how to redeploy the main app; document the cache_interval range and the 24-hour cache.
Addresses Copilot's review of #52. - loadCache only checked that entries was an array, so a cache like entries: [null], or an entry without a title, reached render and could throw instead of showing the error screen. Every entry is now checked: any malformed entry discards the cache, and missing optional text fields default to empty. - Pruning ran after the write, so storage already full of expired caches made every save fail before pruning could free space. It now runs first.
A negative age passed the 24-hour check, so a cache saved while the player's clock was ahead (common before it syncs) stayed fresh for the whole gap. Only an age from 0 to 24 hours now counts as fresh. Reported by Copilot on #52.
fix: tie the feed cache to its feed and expire it, clamp cache_interval



Promotes
developmenttomain. This switches the app's CI to the edge-apps-actions v26.10.2 reusable workflows (Checks, Initialize Edge App, Update Edge App), and brings the README release docs.Important
Merge #45 (
main→development) first. Until then this PR shows conflicts or a brokendevelopment. Merge #47 too: it makes the feed-apps workflow refuse tags that aren't onmain.Changes since
mainAfter merging
main→ deploy to stage, which waits for approval in thestageenvironment.main(vYY.MM.N) and push the tag → deploy to production, which also waits for approval. Tags that aren't onmainare refused.Also included since this PR was opened
modesetting). The photo background is gone, which removes about 900 KB of assets.modedocumented.deployed-apps.ymlis the only source of feed-app ids, and apps without an id for an environment are skipped (ABC and CNN in production).screenly_qc.ymlis deleted: it differed fromscreenly.ymlonly by the main app's stage id, which now comes fromSTAGE_EDGE_APP_ID, so every deploy usesscreenly.yml.cache_intervalis clamped to 60–86400 s.After merging
maindeploys the main app and all 8 feed apps to stage. Each deploy waits for approval instage.mainwithvYY.M.PATCH. Anyv<digit>tag deploys to production, including pre-release tags likev26.11.0-rc.1, so don't push one to test.